pair)
> > I don't know, but from the message it looks like some 'local'
> variables
> > is not saved and defined. I'm surprised that loading some mf file
> works
> > at all (because it also assumes some mf related definitions). I also
> > hav
> > eno clue
lso
hav
eno clue if such a package adopts 'core' metafun code (and mpiv metafun
is different from mpii).
It's a generic, "pure" MetaPost package:
https://www.ctan.org/pkg/cmarrows <https://www.ctan.org/pkg/cmarrows>
that doesn't make it immune from clashes in used variable
I don't know, but from the message it looks like some 'local' variables
> is not saved and defined. I'm surprised that loading some mf file works
> at all (because it also assumes some mf related definitions). I also hav
> eno clue if such a package adopts 'core' metafun code (and mpiv meta
a package adopts 'core' metafun code (and mpiv metafun
is different from mpii).
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
te
Hi,
The 2021 texlive code is currently being frozen. This means that Mojca
will check-in the current context release right before tl gets deep frozen.
The MKII code (mkii and mpii files) hasn't changed so it should still
work well with pdftex and xetex although I admit that I haven't checked
en making vardef's one need to omit the final
semi colon in order to apply more properties to the 'return value'.
At some point I will update the metafun manual which means: remove old
methods and exclusively use the new ones (currently the manual also
discusses mpii while in context mkiv/lm
-ade.nl / http://context.aanhet.net
> archive : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___
>
This is MetaPost, version 2.00 (TeX Live 2018) (kpathsea version 6.3.0) 21 JAN 2019 22:45
**\relax; tracingall; input
On 2013–10–01 Hans Hagen wrote:
in mkiv the overhead is less than in mpii as we don't parse the blob
in the same way and the mpiv code is also more optimized so we can
consider dropping the SetPageState macro.
I see you decided to drop LoadPageState. It's about 20ms overhead
per 1000 graphics
On 10/1/2013 8:35 PM, Marco Patzer wrote:
On 2013–10–01 Hans Hagen wrote:
in mkiv the overhead is less than in mpii as we don't parse the blob
in the same way and the mpiv code is also more optimized so we can
consider dropping the SetPageState macro.
I see you decided to drop LoadPageState
/texmf/metapost/base/string.mp
(/tmp/mkiitest/tex/texmf-context/metapost/context/base/mp-func.mpii) ) )
(end occurred when else on line 5 was incomplete)
That's not mkii but the metafun mpii format generation. I kept that till
now because one never knows is mp has been updated. Todays mpost has
was incomplete)
That's not mkii but the metafun mpii format generation. I kept that
till now because one never knows is mp has been updated. Todays
mpost has no format so that's why it looks like it 'fails' but can
can just ignore it.
Maybe I quoted the wrong part of the log, but it seems like the MkII
) ) )
(end occurred when else on line 5 was incomplete)
That's not mkii but the metafun mpii format generation. I kept that
till now because one never knows is mp has been updated. Todays
mpost has no format so that's why it looks like it 'fails' but can
can just ignore it.
Maybe I quoted
;
\stopMPextensions
(as it load the mpii spec file which redefines transparency to use old
trickery)
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt
-spec; fi;
if unknown context_grph: input mp-grph; fi;
\stopMPextensions
(as it load the mpii spec file which redefines transparency to use old
trickery)
I see. Thanks for the quick fix! :-)
Peter
___
If your
level) for the backgrounds but more
placed might need patching. So, from now on we will also have different
files for mp: mpii and mpiv.
I uploaded a beta, so best do some testing right away as i might have
messed up,
Hans
15 matches
Mail list logo
